Blosxom hcard plugin

Building on my initial set of blosxom microformat plugins, the hcard plugin provides a global hcard variable for inclusion in your blosxom templates.

To use it, you simply define the set of hcard data to use in an 'hcard.yml' file in your blosxom data directory, and then include $hcard::hcard somewhere in your blosxom flavours/template. An example hcard.yml for me might be:

Name: Gavin Carr
Organisation: Open Fusion
Role: Chief Geek
Email: gavin@openfusion.com.au
URL: http://www.openfusion.net/
Suburb: Wahroonga
State: NSW
Postcode: 2076
Country: Australia
Latitude: -33.717718
Longitude: 151.117158
HCard-Class: nodisplay
HCard-Style: div-span

I'm using hcard here, so if you have microformat support in your browser (e.g. via the Operator plugin, if using firefox) you should be able to see my hcard on this page.

As usual, available in the blosxom sourceforge CVS repository.

Blosxom Microformat Plugins

I've been messing around recently with some ideas on adding some initial microformats support to blosxom.

Microformats are fragments of html marked up with some standardised html class names, providing a minimalist method of adding simple structured data to html pages, primarily for machine parsing (try out the firefox Operator plugin to see microformats in action). Some examples of currently defined microformats are contact details (hcard), events (hcalendar), links or bookmarks (xfolk), geolocation (geo), etc. See the main microformats website for more.

With blosxom, one simple approach is to allow microformat attributes to be defined within story metadata, and either autoappend the microformat to the story itself, or simply define the microformat in a variable for explicit inclusion in the story. So for example, if you wanted to geocode a particular story, you could just add:

Latitude: -33.717770
Longitude: 151.115886

or

meta-latitude: -33.717770
meta-longitude: 151.115886

to your story headers (depending on which metadata plugin you're using).

This is the initial approach I've taken, allowing you to attach microformats to stories with a minimum of fuss. So far, the following blosxom microformat plugins are available:

  • uf_adr_meta - adr support
  • uf_geo_meta - geo support
  • uf_hcalendar_meta - hcalendar support
  • uf_hcard_meta - hcard support
  • uf_xfolk_meta - xfolk support

Note that these are beta quality, and may well contain bugs. Feedback especially welcome from microformat gurus. There's also a lot of other ways we might like to handle or integrate microformats - this is just a useful first step.

All plugins are available in blosxom sourceforge CVS repository.

Blosxom Tags

I've been using tags here right from the beginning, because they provide a much more powerful and flexible way of categorising content than do simpler more static categories. This seems to be pretty much the consensus in the blogosphere now.

I started off using xtaran's tagging plugin. The one thing I didn't like about tagging was that it has a fairly brute-force approach to doing tag filtering - it basically just iterates over the set of candidate files and opens up and checks them all, every time.

So I started messing around with adding some kind of tag cache to tagging, so that the set of tags on a post could be captured when a post was created or updated, and thereafter tag filtering could be done by just referencing the tag cache. That means that if you've got 100 posts, your tag query only needs to read one file - the tag cache - instead of all 100 posts.

En route I realised I really wanted a more modular approach to tagging than the tagging plugin uses as well. For instance, I'm experimenting with various kinds of data blogging, like using dedicated special-purpose blogs for recording bookmarks or books or photos. And for some of these blogs I wanted to be able to do basic tagging and querying, but didn't need fancier interface stuff like tagclouds.

So I've ended up creating a small set of blosxom plugins that provide most of the functionality of tagging using a tag cache. The plugins are:

  • tags - provides base tag functionality, including checking for new and updated stories, maintaining the tag cache, and providing tag-based filtering. Requires my metamail plugin.

  • storytags - provides a story level $storytags::taglist variable containing a formatted list of tags, suitable for inclusion in a story template. Requires tags.

  • tagcloud - provides a $tagcloud::cloud variable containing a formatted wikipedia:"tagcloud" of tags and counts, suitable for inclusion in a template somewhere. Requires a hashref of tags and counts, which tags provides, but should be able to work with other plugins.

Note that these plugins are typically less featureful than the tagging plugin, and that tagging includes functionality (related tag functionality, in particular) not provided by any of these plugins. So tagging is still probably a good choice for many people. Nice to have choice, though, ain't it?

All plugins are available in blosxom sourceforge CVS repository.

'entries_timestamp' blosxom plugin

I've tried all three of the current blosxom 'entries' plugins on my blog in the last few months: entries_cache_meta, entries_cache, and the original entries_index.

entries_cache_meta is pretty nice, but it doesn't work in static mode, and its method of capturing the modification date as metadata didn't quite work how I wanted. I had similar problems with the entries_cache metadata features, and its caching and reindexing didn't seem to work reliably for me. entries_index is the simplest of the three, and offers no caching features, but it's pretty dense code, and didn't offer the killer feature I was after: the ability to easily update and maintain the publication timestamps it was indexing.

Thus entries_timestamp is born.

entries_timestamp is based on Rael's entries_index, and like it offers no caching facilites (at least currently). Its main point of difference from entries_index is that it maintains two sets of creation timestamps for each post - a machine-friendly one (a gmtime timestamp) and a human-friendly one (a timestamp string).

In normal use blosoxm just uses the machine timestamps and works just like entries_index, just using the timestamps to order posts for presentation. entries_timestamp also allows modification of the human timestamps, however, so that if you want to tweak the publish date you just modify the timestamp string in the entries_timestamp.index metadata file, and then tell blosxom to update its machine-timestamps from the human- ones by passing a reindex=<$entries_timestamp::reindex_password> argument to blosxom i.e.

http://www.domain.com/blosxom.cgi?reindex=mypassword

It also supports migration from an entries_index index file, explicit symlink support (so you don't have to update timestamps to symlinked posts explicitly), and has been mostly rewritten to be (hopefully) easier to read and maintain.

It's available in the blosxom sourceforge CVS repository.

'mason_blocks' blosxom plugin

I've just released my first blosxom plugin into the wild. 'mason_blocks' is a blosxom plugin implementing simple conditional and comment blocks using HTML::Mason-style syntax, for use in blosxom flavour and template files.

Examples:

# Mason-style conditionals
% if ($pagetype::pagetype ne 'story') {
<a href="$permalink::story#comments">Comments ($feedback::count)</a>
% } else {
<a href="$permalink::story#leave_comment">Leave a comment</a>
% }

# Mason-style comments
%# Only show a comments section if there are comments
% if ($feedback::count > 0) {
$feedback::comments
% }

# Mason-style block comments

I wrote it when I couldn't get the interpolate_fancy plugin to work properly with nested tags, and because I wanted proper perl conditions and if-else support. mason_blocks provides all the conditional functionality of interpolate_fancy, but not other stuff like 'actions'.

mason_blocks is available from the blosxom plugins CVS repository.